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Return Path Specified Label Switched Path (LSP) Ping 


Abstract 


This document defines extensions to the data-plane failure-detection 
protocol for Multiprotocol Label Switching (MPLS) Label Switched 
Paths (LSPs) known as "LSP ping". These extensions allow a selection 
of the LSP to be used for the echo reply return path.  Enforcing a 
Specific return path can be used to verify bidirectional connectivity 
and also increase LSP ping robustness. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7110. 
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1. Introduction 


This document defines extensions to the data-plane failure-detection 
protocol for Multiprotocol Label Switching (MPLS) Label Switched 
Paths (LSPs) known as "LSP ping" [RFC4379] that can be used to 
Specify the return paths for the echo reply message, increasing the 
robustness of LSP ping, reducing the opportunity for error, and 
improving the reliability of the echo reply message. A new Reply 
Mode, which is referred to as "Reply via Specified Path", is added 
and a new Type-Length-Value (TLV), which is referred to as "Reply 
Path (RP) TLV", is defined in this memo. The procedures defined in 
this document currently only apply to "ping" mode. The "traceroute" 
mode is out of scope for this document. 


In this document, the term bidirectional LSP includes the co-routed 
bidirectional LSP defined in [RFC3945] and the associated 
bidirectional LSP that is constructed from a pair of unidirectional 
LSPs (one for each direction) that are associated with one another at 
the LSP's ingress/egress points [RFC5654]. The mechanisms defined in 
this document can apply to both IP/MPLS and MPLS Transport Profile 
(MPLS-TP) scenarios. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Problem Statements and Solution Overview 


MPLS LSP ping is defined in [RFC4379]. It can be used to detect 
data-path failures in all MPLS LSPs. 


LSPs are increasingly being deployed to provide bidirectional 
services. The co-routed bidirectional LSP is defined in [RFC3945], 
and the associated bidirectional LSP is defined in [RFC5654]. With 
the deployment of such services, operators have a desire to test both 
directions of a bidirectional LSP in a single operation. 


Additionally, when testing a single direction of an LSP (either a 
unidirectional LSP or a single direction of a bidirectional LSP) 
using LSP ping, the validity of the result may be affected by the 
success of delivering the echo reply message. Failure to exchange 
these messages between the egress Label Switching Router (LSR) and 
the ingress LSR can lead to false negatives where the LSP under test 
is reported as "down" even though it is functioning correctly. 
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1. Limitations of Existing Mechanisms for Bidirectional LSPs 


With the existing LSP ping mechanisms, as defined in [RFC4379], 
operators have to enable LSP detection on each of the two ends of a 
bidirectional LSP independently. This not only doubles the workload 
for the operators but may also bring additional difficulties when 
checking the backward direction of the LSP under the following 
condition: 


The LSR that the operator logged on to perform the checking 
operations might not have out-of-band connectivity to the LSR at 
the far end of the LSP. That can mean it is not possible to check 
the return direction of a bidirectional LSP in a single operation 
-- the operator must log on to the LSR at the other end of the LSP 
to test the return direction. 


Associated bidirectional LSPs have the same issues as those listed 
for co-routed bidirectional LSPs. 


This document defines a mechanism to allow the operator to request 
that both directions of a bidirectional LSP be tested by a single LSP 
ping message exchange. 


.2. Limitations of Existing Mechanisms for Handling Unreliable Return 


Paths 
[RFC4379] defines four Reply Modes: 


Do not reply 

Reply via an IPv4/IPv6 UDP packet 

Reply via an IPv4/IPv6 UDP packet with Router Alert 
Reply via application level control channel 


SS UN ER 


Obviously, the issue of the reliability of the return path for an 
echo reply message does not apply in the first of these cases. 


[RFC4379] states that the third mode may be used when the IP return 


path is deemed unreliable. This mode of operation requires that all 
intermediate nodes support the Router Alert option and understand how 
to forward MPLS echo replies. This is a rigorous requirement in 


deployed IP/MPLS networks, especially since the return path may be 
through legacy IP-only routers. 
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In any case, the use of Reply Modes 2 or 3 cannot guarantee the 
delivery of echo responses through an IP network that is 
fundamentally unreliable. The failure to deliver echo response 
messages can lead to false negatives, making it appear that the LSP 
has failed. 


Allowing the ingress LSR to control the path used for echo reply 
messages enables an operator to apply an extra level of deterministic 
process to the LSP ping test. For example, when testing an LSP, 
Reply Mode 2 is used at the beginning but no echo reply is received. 
When failure of the return path is suspected, the operator can 
initiate another LSP ping with the Reply Mode defined in this 
document and specify a different return path that is deemed workable 
to complete the test. 


This document defines extensions to LSP ping that can be used to 
specify the return paths of the echo reply message in an echo request 
message. 


4. Extensions 


LSP ping, defined in [RFC4379], is carried out by sending an echo 
request message. It carries the Forwarding Equivalence Class (FEC) 
information of the LSP being tested. The FEC information indicates 
which MPLS path is being verified along the same data path as other 
normal data packets belonging to the FEC. 


LSP ping [RFC4379] defines four Reply Modes that are used to direct 
the egress LSR in how to send back an echo reply. This document 
defines a new Reply Mode, the "Reply via Specified Path" mode. This 
new mode is used to direct the egress LSR of the tested LSP to send 
the echo reply message back along the path specified in the echo 
request message. 


In addition, two new TLVs, the "Reply Path (RP) TLV" and "Reply 
Traffic Class (TC) TLV" [RFC5462], are defined in this document. The 
Reply Path TLV contains one or more nested sub-TLVs that can be used 
to carry the specified return path information to be used by the echo 
reply message. 


Chen, et al. Standards Track [Page 5] 


RFC 7110 Return Path Specified LSP Ping January 2014 


4.1. Reply via Specified Path Mode 


A new Reply Mode is defined to be carried in the Reply Mode field of 
the echo request message. 


The value of the Reply via Specified Path mode is 5 (This has been 
allocated by IANA using early allocation and is to be confirmed by 
IANA). 


5 Reply via Specified Path 


The Reply via Specified Path mode is used to request that the remote 
LSR receiving the echo request message sends back the echo reply 
message along the specified paths carried in the Reply Path TLV. 


4.2. Reply Path (RP) TLV 


The Reply Path (RP) TLV is an optional TLV within the LSP ping 
protocol. However, if the Reply via Specified Path mode requested, 
as described in Section 4.1, the Reply Path (RP) TLV MUST be included 
in an echo request message, and its absence is treated as a malformed 
echo request, as described in [RFC4379]. Furthermore, if a Reply 
Path (RP) TLV is included in an echo request message, a Reply Path 
(RP) TLV MUST be included in the corresponding echo reply message 
sent by an implementation that is conformant to this specification. 


The Reply Path (RP) TLV carries the specified return path that the 
echo reply message is required to follow. The format of Reply Path 
TLV is as follows: 


0 1 2 3 
012345678901234567890123456780901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Reply Path TLV Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reply Path return code | Flags 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reply Path | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Reply Path TLV 
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Reply Path TLV Type: It is 2 octets in length, and the type value is 
21. 


Length: It is 2 octets in length. It defines the length in octets 
of the Reply Path return code, Flags, and Reply Path fields. 


Reply Path return code: The Reply Path return code field is 2 octets 
in length. It is defined for the egress LSR of the forward LSP to 
report the results of Reply Path TLV processing and return path 
selection. This field MUST be set to zero in a Reply Path TLV 
carried on an echo request message and MUST be ignored on receipt. 
This document defines the following Reply Path return codes for 
inclusion in a Reply Path TLV carried on an echo reply: 


Value Meaning 

0x0000 Reserved, MUST NOT be used 

0x0001 Malformed Reply Path TLV was received 

0x0002 One or more of the sub-TLVs in the Reply Path TLV 
were not understood 

0x0003 The echo reply was sent successfully using the 
specified Reply Path 

0x0004 The specified Reply Path was not found, the echo 
reply was sent via another LSP 

0x0005 The specified Reply Path was not found, the echo 
reply was sent via pure IP forwarding (non-MPLS) 
path 


0x0006-0xfffb Unassigned 
Oxfffc-Oxffff Experimental Use 
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Flags: It is also 2 octets in length, it is used to notify the 
egress how to process the Reply Paths field when performing return 
path selection. The Flags field is a bit vector and has following 
format: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

MUST be zero |A|B| 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 2: Flags 


A (Alternative path): the egress LSR MUST select a non-default 
path as the return path. This is very useful when reverse 
default path problems are suspected that can be confirmed when 
the echo reply is forced to follow a non-default return path. 
Here, the default path refers to the path that the egress LSR 
will use to send the echo reply when Reply Mode 2 or 3 is used. 
If A bit is set, there is no need to carry any specific reply 
path sub-TLVs, and when received, the sub-TLVs SHOULD be 


ignored. 
B (Bidirectional): the return path is required to follow the 
reverse direction of the tested bidirectional LSP. If B bit is 


set, there is no need to carry any specific reply path sub- 
TLVs, and when received, the sub-TLVs SHOULD be ignored. 


The A flag and B flag MUST NOT both be set, otherwise, an echo 
reply with the RP return code set to "Malformed Reply Path TLV 
was received" MUST be returned. 


Reply Path: It is used to describe the return path that an echo 
reply will be send along. It is variable in length and can 
contain zero, one or more Target FEC sub-TLVs [RFC4379]. In an 
echo request, it carries sub-TLVs that describe the specified path 
that the echo reply message is required to follow. In an echo 
reply, the sub-TLVs describe the FEC Stack information of the 
return path (when the return path is an MPLS path) that the echo 
reply will be sent along. 


4.3. Tunnel Sub-TLVs 


[RFC4379] has already defined several Target FEC sub-TLVs, the Target 
FEC sub-TLVs provide a good way to identify a specific return path. 
The Reply Path TLV can carry any (existing and future defined) sub- 
TLV defined for use in the Target FEC Stack TLV to specify the return 
path. 
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This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel 
sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One 
usage of these generic RSVP Tunnel sub-TLVs is when LSP ping is used 
to periodically verify the control plane against the data plane 
[RFC5884], using a Tunnel other than a particular LSP can avoid the 
impact of an LSP identifier changing when Make-Before-Break (MBB) is 
deployed. These sub-TLVs also can be used in the Reply Path TLV to 
allow the operator to specify a more generic tunnel FEC other than a 
particular LSP as the return path. 


No assignments of sub-TLVs are made directly for TLV Type 21, the 
sub-TLV space and assignments for TLV Type 21 will be the same as 
that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 MUST 
be kept the same. Any new sub-type added to TLV Type 1 MUST apply to 
the TLV Type 21 as well. 
With the Return Path TLV flags and the sub-TLVs defined for the 
Target FEC Stack TLV and in this document, it could provide the 
following options for return paths specifying: 
1. a particular LSP as return path 
- use those sub-TLVs defined for the Target FEC Stack TLV 
2. amore generic tunnel FEC as return path 
- use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in 
Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of 
this document 
3. the reverse path of the bidirectional LSP as return path 
- use B bit defined in Section 4.2 of this document. 


4. Force return path to non-default path 


- use A bit defined in Section 4.2 of this document. 
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203 os IPv4 RSVP Tunnel Sub-TLV 
The format of the IPv4 RSVP Tunnel sub-TLV is as follows: 


0 1 2 3 
OL 23.4 5.6 7 8 9/0 1:2.3 4.5.6 7 8::9 0 1-2.3 4 560 7 8:9.00 1 
d+ A A O O A O A O O O o o o o + + + 

| IPv4 RSVP Tunnel sub-TLV Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+ O O O o O o o o + + + 
| IPv4 tunnel end point address 
—-——R---—R--—4-4-R-—-4-4-4-—-4-L---4-94-4--- o + + + 
| Flags | Tunnel ID | 
—-4—R—R-—-4-—R--—4-4-R-—-4-4-4—-4-9L-4-—-4-94---4-94--v-4-9 
| Extended Tunnel ID | 
d+ A A O O O O O A O o O o o o o o + + + 
| IPv4 tunnel sender address 

d+ O A O O A O O A O o O o O o o + ++ + 


Figure 3: IPv4 RSVP Tunnel Sub-TLV 


The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV 
that is defined in Section 3.2.3 of [RFC4379]. All fields have the 
same semantics as defined in [RFC4379] except that the LSP-ID field 
is omitted and a new Flags field is defined. 


The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 
the recommended type value is 26. 


The Flags field is 2 octets in length, it is used to notify the 
egress LSR how to choose the return path. The Flags field is a bit 
vector and has following format: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MUST be zero |s|P| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 4: Tunnel Flags 


P (Primary): the return path MUST be chosen from the LSPs that belong 
to the specified Tunnel and the LSP MUST be the primary LSP. 


S (Secondary): the return path MUST be chosen from the LSPs that 


belong to the specified Tunnel and the LSP MUST be the secondary LSP. 
Primary and secondary LSPs are defined in [RFC4872]. 
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P bit and S bit MUST NOT both be set, otherwise, an echo reply with 
the RP return code set to "Malformed Reply Path TLV was received" 
SHOULD be returned. If P bit and S bit are both not set, the return 
path could be any one of the LSPs from the same Tunnel. 


4.3.2.  IPv6 RSVP Tunnel Sub-TLV 
The format of the IPv6 RSVP Tunnel sub-TLV is as follows: 


0 I 2 3 
0:1: 2-3) A 5. 6 7:8 9.0 1 2.34 56 78:9 0 1 2.3 4 5.0.7.8 9 0 L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IPv6 RSVP Tunnel sub-TLV Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 tunnel end point address 
ETC 
| Flags | Tunnel ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Extended Tunnel ID 


+A A A A O + e e + + $ + + + ++ + ++ +++ +++ += +++ 
IPv6 tunnel sender address | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ ———— + —— 


Figure 5: IPv6 RSVP Tunnel Sub-TLV 


The IPv6 RSVP Tunnel sub-TLV is derived from the RSVP IPv6 FEC TLV 
that is defined in Section 3.2.4 of [RFC4379]. All fields have the 
same semantics as defined in [RFC4379] except that the LSP-ID field 
is omitted and a new Flags field is defined. 


The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and 
the type value is 27. 


The Flags field is 2 octets in length and is identical to that 
described in Section 4.3.1. 
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4.3.3. Static Tunnel Sub-TLV 


The format of the Static RSVP Tunnel sub-TLV is as follows. The 
value fields are taken from the definitions in [RFC6370]. 


0 1 2 3 
0123456789 0123456789012345678901 
—————————————AA—^A^A^ A A A A A ———R———R——————€——————— ig 
Static Tunnel sub-TLV Type | Length 
a 4-4-4 ^———— it 
Source Global ID | 
———R^————^——^A——^A——^A^A^A^A^ ^R^R^A——W^—— ^^——————RARA^ARW^A^——»—»—————— € 
Source Node ID | 
KA A A A A A A A A A A A A A^————RR——————À 
Destination Global ID | 
KA A A A A A A A 4-4-4 4-4-4 ^A————————————————— gig it 
Destination Node ID | 
—f-f-4-4-4-4-4-4- 4-4-4 A A A———————————————— o 
Source Tunnel Num | Destination Tunnel Num 
KA A A A A A 4-4-4 4-4-4 R^A^———^ —————R———»—AR—————! 
Flags | Must Be Zero | 
KA A A A A A A A A A A A A pp papi pip i pip o o o o git 


+— + —+—+—+—+—+—+ 


Figure 6: Static Tunnel Sub-TLV 


The Flags field is 2 octets in length and is identical to that 
described in Section 4.3.1. 


The sub-TLV type value is 28. 
4.4. Reply TC TLV 


Reply TOS Byte TLV [RFC4379] is used by the originator of the echo 
request to request that an echo reply be sent with the IP header TOS 
byte set to the value specified in the TLV. Similarly, in this 
document, a new TLV, Reply TC TLV, is defined and MAY be used by the 
originator of the echo request to request that an echo reply be sent 
with the TC bits of the return path LSP set to the value specified in 
this TLV. The Reply TC TLV is not limited to the Reply Mode 
specified in this document (Reply via Specified Path) but may be used 
in all the other Reply Modes as well. The format of Reply TC TLV is 
as follows: 
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0 1. 2 3 
0:43. .2-3:4 56, 7 89:0. 1.2 3 4 5-6 7.8 9:02. 3.4-5» 6: 7 8.9.0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Reply TC TLV type | Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
oom MUST be zero | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


H 


+ 
+ 
Figure 7: Reply TC TLV 


The Reply TC TLV Type field is 2 octets in length, and the type value 
LS 22. 


The Length field is 2 octets in length, the value of length field is 
fixed 4 octets. 


5. Theory of Operation 


The procedures defined in this document currently only apply to 
"ping" mode. The "traceroute" mode is out of scope for this 
document. 


In [RFC4379], the echo reply is used to report the LSP checking 
result to the LSP ping initiator. This document defines a new Reply 
Mode and a new TLV (Reply Path TLV) that enable the LSP ping 
initiator to specify or constrain the return path of the echo reply. 
Similarly, the behavior of echo reply is extended to detect the 
requested return path by looking at a specified path FEC TLV. This 
enables LSP ping to detect failures in both directions of a path with 
a single operation; of course, this cuts in half the operational 
steps required to verify the end-to-end bidirectional connectivity 
and integrity of an LSP. 


When the return path is an MPLS path, the echo reply MUST carry the 
FEC Stack information in a Reply Path TLV to test the return MPLS LSP 
path. The destination IP address of the echo reply message MUST 
never be used in a forwarding decision. To avoid this possibility 
the destination IP address of the echo reply message that is 
transmitted along the specified return path MUST be set to numbers 
from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for 
IPv6, and the IP Time to Live (TTL) MUST be set 1, and the TTL in the 
outermost label MUST be set to 255. 


When the return path is a pure IP forwarding path, the procedures 


defined in [RFC4379] (the destination IP address is copied from the 
source IP address) apply unchanged. 
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1. Sending an Echo Request 


When sending an echo request, in addition to the rules and procedures 
defined in Section 4.3 of [RFC4379], the Reply Mode of the echo 
request MUST be set to "Reply via Specified Path", and a Reply Path 
TLV MUST be carried in the echo request message correspondingly. The 
Reply Path TLV includes one or several reply path sub-TLV(s) to 
identify the return path(s) the egress LSR should use for its reply. 


For a bidirectional LSP, since the ingress LSR and egress LSR of a 
bidirectional LSP are aware of the relationship between the forward 
and backward direction LSPs, only the B bit SHOULD be set in the 
Reply Path TLV. If the operator wants the echo reply to be sent 
along a path other than the reverse direction of the bidirectional 
LSP, the A bit SHOULD be set or another FEC sub-TLV SHOULD be carried 
in the Reply Path TLV instead, and the B bit MUST be clear. 


In some cases, operators may want to treat two unidirectional LSPs 
(one for each direction) as a pair. There may not be any binding 
relationship between the two LSPs. Using the mechanism defined in 
this document, operators can run LSP ping one time from one end to 
complete the failure detection on both unidirectional LSPs. To 
accomplish this, the echo request message MUST carry (in the Reply 
Path TLV) a FEC sub-TLV that belongs to the backward LSP. 


.2. Receiving an Echo Request 


"Ping" mode processing, as defined in Section 4.4 of [RFC4379], 
applies in this document. In addition, when an echo request is 
received, if the egress LSR does not know the Reply Mode defined in 
this document, an echo reply with the return code set to "Malformed 
echo request received" and the Subcode set to zero will be send back 
to the ingress LSR according to the rules of [RFCA4379]. If the 
egress LSR knows the Reply Mode, according to the Reply Path TLV, it 
SHOULD find and select the desired return path. If there is a 
matched path, an echo reply with a Reply Path TLV that identifies the 
return path SHOULD be sent back to the ingress LSR, the Reply Path 
return code SHOULD be set to "The echo reply was sent successfully 
using the specified Reply Path". If there is no such path, an echo 
reply with the Reply Path TLV SHOULD be sent back to the ingress LSR, 
the Reply Path return code SHOULD be set to the relevant code 
(defined in Section 4.2) for the real situation to reflect the result 
of Reply Path TLV processing and return path selection. For example, 
if the specified LSP is not found, the egress then chooses another 
LSP as the return path to send the echo reply, the Reply Path return 
code SHOULD be set to "The specified reply path was not found, the 
echo reply was sent via another LSP", and if the egress chooses an IP 
path to send the echo reply, the Reply Path return code SHOULD be set 
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to "The specified Reply Path was not found, the echo reply was sent 
via pure IP forwarding (non-MPLS) path". If there is an unknown sub- 
TLV in the received Reply Path TLV, the Reply Path return code SHOULD 
be set to "One or more of the sub-TLVs in the Reply Path TLV were not 
understood". 


If the A bit of the Reply Path TLV in a received echo request message 
is set, the egress LSR SHOULD send the echo reply along a non-default 
return path. 


If the B bit of the Reply Path TLV in a received echo request message 
is set, the egress LSR SHOULD send the echo reply along the reverse 
direction of the bidirectional LSP. 


In addition, the FEC validate results of the forward path LSP SHOULD 
NOT affect the egress LSR continue to test return path LSP. 


5.3. Sending an Echo Reply 


As described in [RFC4379], the echo reply message is a UDP packet, 
and it MUST be sent only in response to an MPLS echo request. The 
source IP address is a valid IP address of the replier, the source 
UDP port is the well-know UDP port for LSP ping. 


When the return path is an MPLS LSP, the destination IP address of 
the echo reply message is copied from the destination IP address of 
the echo request, and the destination UDP port is copied from the 
source UDP port of the echo request. The IP TTL MUST be set to 1, 
the TTL in the outermost label MUST be set to 255. 


When the return path is a pure IP forwarding path, the same as 
defined in [RFC4379], the destination IP address and UDP port are 
copied from the source IP address and source UDP port of the echo 
request. 


When sending the echo reply, a Reply Path TLV that identifies the 
return path MUST be carried, the Reply Path return code SHOULD be set 
to relevant code that reflects results about how the egress processes 
the Reply Path TLV in a previous received echo request message and 
return path selection. By carrying the Reply Path TLV in an echo 
reply, it gives the ingress LSR enough information about the reverse 
direction of the tested path to verify the consistency of the data 
plane against control plane. Thus, a single LSP ping could achieve 
both directions of a path test. If the return path is pure IP path, 
no sub-TLVs are carried in the Reply Path TLV. 
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5.4. Receiving an Echo Reply 


The rules and process defined in Section 4.6 of [RFC4379] apply here. 
When an echo reply is received, if the Reply Mode is "Reply via 
Specified Path" and the Reply Path return code is "The echo reply was 
sent successfully using the specified Reply Path", and if the return 
path is an MPLS LSP. The ingress LSR MUST perform FEC validation 
(based on the FEC Stack information of the return path carried in the 
Reply Path TLV) as an egress LSR does when receiving an echo request, 
the FEC validation process (relevant to "ping" mode) defined in 
Section 4.4.1 of [RFC4379] applies here. 


When an echo reply is received with return code set to "Malformed 
echo request received" and the Subcode set to zero. It is possible 
that the egress LSR may not know the "Reply via Specified Path" Reply 
Mode, the operator may choose to re-perform another LSP ping by using 
one of the four Reply Modes defined [RFC4379]. 


On receipt of an echo reply with Reply Path return code in the Reply 
Path TLV set to "The specified reply path was not found, ...", it 
means that the egress LSR could not find a matched return path as 
specified. Operators may choose to specify another LSP as the return 


path or use other methods to detect the path further. 
5.5. Non-IP Encapsulation for MPLS-TP LSPs 


In some MPLS-TP deployment scenarios, IP addressing might not be 
available or the use of some form of non-IP encapsulation might be 
preferred. In such scenarios, the Non-IP encapsulation defined in 
[RFC6426] applies here. The LSP Ping Reply Mode in the echo request 
and echo reply is set to 5. The return path of the echo reply is as 
specified in the Reply Path TLV. 


6. Security Considerations 


Security considerations discussed in [RFC4379] apply to this 
document. 


In addition, the extensions defined in this document may be used for 
potential "proxying" attacks. For example, an echo request initiator 
may specify a return path that has a destination different from that 
of the initiator. But normally, such attacks will not happen in an 
MPLS domain where the initiators and receivers belong to the same 
domain. Even this, in order to prevent using the extension defined 
in this document for proxying any possible attacks, the return path 
LSP should have destination to the same node where the forward path 
is from. The receiver may drop the echo request when it cannot 
determine whether the return path LSP has the destination to the 
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initiator. That means, when sending echo request, the initiator 
should choose a proper source address according the specified return 
path LSP to help the receiver to make the decision. 


7. IANA Considerations 

7.1. TLVs 
TANA has assigned the value 21 for the Reply Path TLV and assigned 
the value 22 for Reply TC TLV from the "Multiprotocol Label Switching 


Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" 
registry, "TLVs" subregistry. 


Value Meaning Reference 
21 Reply Path TLV this document (Section 4.2) 
22 Reply TC TLV this document (Section 4.4) 


The sub-TLV space and assignments for the Reply Path TLV will be the 
same as that for the Target FEC Stack TLV. Sub-types for the Target 
FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new 
sub-type added to the Target FEC Stack TLV MUST apply to the Reply 
Path TLV as well. 


7.2. New Target FEC Stack Sub-TLVs 
IANA has assigned three new sub-TLV types from the "Multiprotocol 


Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping 
Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21" 


subregistry. 

Sub-Type Sub-TLV Name Reference 

26 IPv4 RSVP Tunnel this document (Section 4.3.1) 
27 IPv6 RSVP Tunnel this document (Section 4.3.2) 
28 Static Tunnel this document (Section 4.3.3) 


7.3. New Reply Mode 


IANA has allocated (5 - Reply via Specified Path) from the "Multi- 
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 
Parameters" registry, the "Reply Modes" subregistry. 


Value Meaning Reference 


5 Reply via Specified Path this document (Section 4.1) 
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7.4. Reply Path Return Code 
IANA has created a new subregistry for the "Multi-Protocol Label 
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for 
Reply Path return codes. 


This document (Section 4.2) defines the following return codes: 


Value Meaning 

0x0000 No return code 

0x0001 Malformed Reply Path TLV was received 

0x0002 One or more of the sub-TLVs in the Reply Path TLV 
were not understood 

0x0003 The echo reply was sent successfully using the 
specified Reply Path 

0x0004 The specified Reply Path was not found, the echo 
reply was sent via another LSP 

0x0005 The specified Reply Path was not found, the echo 
reply was sent via pure IP forwarding (non-MPLS) 
path 


0x0006-0xfffb Unassigned 
Oxfffc-Oxffff Reserved for Experimental Use 


The range of 0x0006-Oxfffb is not allocated and reserved for future 


extensions and is allocated via Standard Action; the range of Oxfffc- 
Oxffff is for Experimental Use. 
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